FSP 2.3 has been superceded by FSP 2.6, but documentation has not been rewritten. Use this document as a base, and refer to 'FSP 2.6 Notes' for up-to-date information on changes and new features.
Introduction
FSP is a tool designed to ease the burden of RRhost sysops trying to keep multiple file sections in a organized state. It can do any number of operations, of varying complexity, by varying the sequence of control commands, including but not limited to the following:
• Catalog file sections in one of 5 different formats including a tab-formatted database-compatible format, or using user-defined formats.
• Automatically backup file sections.
• Merge file sections.
• Sort file sections, collections of file sections, and FS catalogs by one of 5 different keys including Title, Date, Size, Pathname (real file name), and Uploader. The sort may be ascending or descending.
• Detect and optionally delete duplicate file entries.
• Set, clear, and correct pathnames.
• List new file entries since one or more arbitrary dates.
• Detect differences between two file sections.
• Automatically delete old files from the RRhost environment.
• Automatically start other applications.
• Update paths for files that have been moved or deleted.
• Delete actual file when BBS reference is marked for deletion.
FSP is designed to work on file sections as lists of files and is not intended to provide individual editing capability, such as those implemented in the excellent Host File Editor.
Background
The Huntsville Mac Users Group BBS resides in a computer store (I'll give them a plug since they provide the hardware and the phone line: AC3 Computers.) and the intersection of their operating hours and the times that I can spend doing BBS maintenance is quite small, leading to big problems trying to keep the file references straight. The store personnel do a fairly good job of moving recent uploads and keeping the RRHost references in order, but they can't spend much time doing it and things do go awry fairly often, leading to the dreaded 'file not found' message, and the resultant irate user. FSP is meant to automate file section maintenance so that the store personnel do not have to do anything other than running the program.
FSP reads in a command file, named 'FSP Control' that contains instructions on what to do to the files (the instructions will be covered later) and produces another file, 'FSP Log', echoing the input and showing the procession. The FSP Log file is date-stamped so that the sysop can easily tell when FSP was last executed. (Remember the program will generally be started by local people.)
In general, all of the functions provided by FSP work on a list of files in memory which is created by 'Loading' or 'Add'ing a RRHost file section. Once in memory, the list can be sorted and processed in various ways, then output as either a text file or another file section. This should become clear after reviewing the commands and some examples
FSP Command Syntax
FSP reads a sequence of commands from 'FSP' in order to do a programmed set of file section operations without any requiring any understanding of RRHost by the operator (i.e. an AC3 employee). Each command is a single word, possibly followed by an command option, at least one blank, and one to three string arguments, each of which must be contained in double quotes. If a semicolon appears outside of an argument, the rest of the line is ignored. If a command line begins with either a '*' the entire line is ignored as a comment. All commands and command options may be in either upper, lower, or mixed case, though uppercase is recommended. All commands must begin in the first column of the line. Any unrecognized commands are flagged as 'unknown'. Spacing between commands and arguments, and between arguments is optional.
Examples:
COMMAND/OPTION "Argument1"
COMMAND "Argument1" "Argument2" ; Comment!
Command "Argument1" ; "Not an argument - past semicolon."
Symbols and Symbol Replacement
FSP 'programming' is greatly simplified by a relatively powerful symbol substitution capability, allowing the user to define a symbol at the beginning of the FSP program and use the defined symbol as shorthand in the rest of the program. For example, if all RRHost sections, DL1-DL9, reside on 'Dataframe:Applications:BBS:Sections', then 'where' can be defined as 'Dataframe:Applications:BBS:Sections', allowing references to sections as "where:DL1". Defined symbols are restricted to 31 characters, while the string definition may be up to 80 characters. The current version supports 36 symbols. Use of symbols will be covered in more detail later.
When used in a command, a symbol is valid/translated only at the beginning of an argument. For example, if "x" is defined as "This", then the argument "x:Test:x" will be treated as "This:Test:x". Symbols are case-sensitive, so that "x" and "X" are not considered identical. If "x" is defined as above and "X" is undefined, then the argument "X:Test" is considered "X:Test".
With few exceptions, all FSP arguments are checked for defined symbols, and any matches are replaced by the original string, which may have included predefined symbols. The four exceptions are the first argument of the four symbol-defining commands. Examples are in order:
"w" "x" "y" "z"
DEFINE "w" "1" 1 x y z
DEFINE "w" "y#" y# x y z
DEFINE "y" "7" 123 x 7 z
DEFINE "w" "y#" 7# x 7 z
DEFINE "x" "w8" 7# 7#8 7 z
DEFINE "w" "w:w" 7#:w x 7 z
DEFINE "z" "w:z" 7#:w x 7 7#:z
This may be a bit confusing at this point, but both the use of symbols and the reasons for implementing them should become clear as more realistic examples are provided.
Special Symbols
FSP uses six symbols in special ways, though the user/programmer is free to redefine them, if necessary. Symbols "@1", "@2", and "@3" are automatically defined as the three arguments of a macro when invoked, so that these symbols may be used within a macro to refer to the input arguments. This will become clear later, or, if it doesn't, don't use macros. Outside of macros these symbols may be used as any other symbol and are useful as temporary symbols, but be aware that they will get redefined by the next macro call.
The other special symbols are 'Date', 'Remote', and 'BBS'.; "Date' is set to the current date at the time FSP is started, in "<month>/<day>" format. This symbol can be appended to file names in order to provide dated backup capability. Upon FSP startup, '@1' is set to the current month (1-12) and "@2" is set to the current day. The file deletion uses Date in the logs.
The symbol, 'BBS', is used if the RRHost system uses partial pathnames, in which case 'BBS' should be defined as the path to the same folder as RRHost . See CHECK/PATH for details.
The symbol 'Remote' is 'YES' if the file 'LaunchRRH' is present on the same folder as FSP. This indicates that RRHost has started FSP as a Cmd #50 program, and can be used to control operations based on that knowledge.
Guards
Many of the commands use an optional 'guard' symbol as the last argument. This is a simple means of providing conditional behavior within the FSP program. If the symbol, following any possible substitution, is equal to "", "YES", "TRUE", "NO-", or "FALSE-", then the command is executed; otherwise it is skipped. Leaving the guard absent is equivalent to a value of "", so the instruction is always executed.
Examples:
DEFINE "Flag" "YES"
Command1 <required arguments> "Flag"
Command2 <required arguments> "Flag-"
In the preceding example, Command1 will be executed and Command2 will not. If "Flag" is changed to "NO", then the opposite is true. This is particularly useful if there are exclusive commands in the FSP Control file that are guarded by "Flag", so that the Sysop can enable/disable them by changing a single command.
FSP Commands
Symbol Commands
DEFINE "<arg1>" "<arg2>" "<guard>"
DEFINE/NOMAP "<arg1>" "<arg2>" "<guard>"
Define the string <arg1> such that if any argument used in the rest of the FSP "program" begins with <arg1>, <arg1> will be replaced by <arg2>. If the NoMap option is used, no symbol replacement occurs in <arg2>, i.e. the text is used exactly as it is typed.
Examples:
DEFINE "A" "Dataframe:BBS"
DEFINE "x" "A:Downloads"
*LOAD "x:DAs" * is equivalent to LOAD "Dataframe:BBS:Downloads:DAs"
DEFINE "AC3" "YES"
DEFINE "q" "AC3 Xfer Disk"
DEFINE/NoMap "p" "AC3 Xfer Disk"
* q = "YES Xfer Disk" ; p = "AC3 Xfer Disk" ; (based on a true-life problem!)
SHOWSYMBOL "<symbol>"
The symbol, after any necessary substitutions, is shown on the screen and copied to the log file. If the above DEFINES are assumed, SHOWSYMBOL "x" would output "Dataframe:BBS:Downloads".
CONCATENATE "<symbol>" "<arg2>" "<arg3>"
Arg1 is defined as the concatenation of <arg2> and <arg3>. Substitutions
are active for the 2nd and 3rd arguments.
DEFINE "x" ":Sections:DL1"
DEFINE "x" "x as of" "Date"
SAVETEXT "x" is equivalent to SAVETEXT ":Sections:DL1 as of 1/24"
EQUAL "<arg1>" "<arg2>" "<arg3>"
EQUAL/NOT"<arg1>" "<arg2>" "<arg3>"
If <arg2> is the same as <arg3>, then <arg1> is defined as "YES"; otherwise <arg1> is set to "NO". The '/NOT' option flips the logic so that <arg1> is set to 'YES' if the other arguments are not equal.
AND "<arg1>" "<arg2>" "<arg3>"
AND/NOT"<arg1>" "<arg2>" "<arg3>"
If <arg2> and <arg3> are both 'YES' as defined by the Guard criteria, then <arg1> is defined as "YES"; otherwise <arg1> is set to "NO". The '/NOT' option flips the logic so that <arg1> is set to 'YES' if the other arguments are not true. 'AND/NOT"<arg1>" "<arg2>-" "<arg3>-" ' is equivalent to an 'OR'.
FSP Control Commands
SKIP ; Skip 1 line
SKIP "<Label>" ; Skip to label
SKIP "#<number>" ; Skip <number> lines.
SKIP "<Label>" "<key>" ; Conditionally skip to label.
One or more following lines are ignored, i.e. the commands are not executed. A <label> can be any string that starts in the first column of a subsequent line, though that line will not be executed. If <key> is 'TRUE" based on the same criteria as Guards with the addition of "SKIP".
Examples:
DEFINE "Flag" "TRUE"
SKIP "*Label"
SKIP "#4"
SKIP "*Label" "Flag"
SKIP "#2" "Flag"
SKIP
*Label LOAD "x" ; This line will be the next executed;
* ; All of the SKIPs will reach here, though if this
* ; were actually executed all but the first SKIP would be
* ; skipped. See the example files for more meaningful examples.
END "<guard>"
Stop executing FSP immediately (if <guard> is true).
LAUNCH "<Application name>" "<guard>"
FSP stops and the specified application, which must be on the same folder as FSP, is started. This command can be used to kick off RRHost after file section maintenance is complete. On the HSv. MUG BBS, FSP has been renamed to 'Start the BBS!' to ensure that this maintenance occurs regularly. Version 2.3 checks the validity of the application name.
CHAIN "<file name>" "<Label>" "<guard>"
FSP command interpratation is continued at the specfied label within the specified file. If the file name is unspecified, the current command file is used. If the label is unspecified, the first line of the file is the default. This can be used as a "Jump" command, but it should used with caution, as it's possible to set up infinite loops.
LIST Manipulation Commands
LOAD "<file sect pathname>"
The specified file section will be read into memory as a list of file references. Previous file references in memory are discarded, so only file references in the specified Section will be in the list. If the argument specifies a nonexistent file section, FSP will create an empty file section with that name. If the path is invalid, then FSP will terminate immediately, with an error message in the FSP Log file.
SAVE "<arg>" "<guard>
SAVE/DELETE "<arg>" "<guard>
The list of file references in memory is written to disk as a file section named <arg1>. Again, the path name must be correct. The order of file references is maintained so that if any sorts have been performed, the sort will show in the resulting file section. Any file references within the file section on disk are lost (overwritten) if they do not exist within the list in memory. If the 'DELETE' option is used, only file references that are marked for deletion are written.
SAVE/MONTH "<arg>" "<1-12>" "<guard>
Only file references that were uploaded within the specfied month are saved to the specfied file section. Previous caveats apply.
CLEAR
The list (in memory) is cleared. All references that have not been saved are lost.
ADD "<file section name>"
The file references contained in the specified file section will be added to the list in memory. This is similar to a merge and is often followed by a SORT. Previous file references within memory are preserved.
ADDTO "<file section name>"
ADDTO/DELETE "<file section name>"
The current list, in memory, is added to the specified file section . Previous file references within memory are preserved. If the DELETE option is specified, only file references that are marked as deleted are added to the specified section.
SUBTRACT "< file section name >"
All file entries that are in both the list (in memory) and the specified file section are discarded from the list. This is one of the longer operations in terms of execution time. It is also quite powerful when combined with other commands, as will be shown in the more comprehensive examples.
LOAD "Sect1"
SUBTRACT "Sect2"
SAVE "Sect1"
* At this point, Sect1 will not contain any files.
* that are also listed in Sect2.
PURGE "Guard>"
PURGE/DELETE "Guard>"
All file entries in memory are examined; any that are marked for deletion (First byte <> 0) are discarded. The '/DELETE' option will cause FSP to physically delete referenced files! This allows the Mac file system to track deletions within the BBS, but obviously it must be used with care.
All files that are deleted (and any attempted deletions) are appended to a file named "FSP Deletions", which is created if necessary.
SORT/DATE
SORT/TITLE
SORT/PATH
SORT/UPLDR
SORT/SIZE
The list in memory is reordered according to the specfied field. TITLE, UPLDER, and PATH are sorted in ascending order, so that 'A's will be at the beginning of the list, while DATE and SIZE are sorted in descending order. This is consistent with the Finder View options, so that sorted file section lists can be easily compared with 'Print Catalog' printouts.
INVERT
This reverses the order of the list, and is used primarily to produce descending sorts. It can also be used prior to a DELETEDUPS command to control which duplicate file entries are deleted.
SAVETEXT "<Text file name>" "<guard>"
SAVETEXT/BRIEF "<Text file name>" "<guard>"
SAVETEXT/LONG "<Text file name>" "<guard>"
SAVETEXT/DESC "<Text file name>" "<guard>"
SAVETEXT/PATH "<Text file name>" "<guard>"
SAVETEXT/FORMAT "<Text file name>" "<guard>"
The list of files is saved in text form. The /BRIEF mode will produce an 'Edit' file with the Title, Size, Upload Date, Clearance, and Uploader. One line is used for each entry, which are listed in the same order as they occur in memory. The default mode (no option) will produce 3 lines of output per entry, with the first line identical to the /BRIEF mode, the second line containing the file type (MacDoc, MacAppl, Other, or Text) and the description, and the third line will contain the Path. The /LONG option will produce output very similar to the default mode except that all output is on one line with tab field separators. This may be used as input to databases, though this has not been tested. This format may also be used to produce editable output which may be read with the 'READTEXT' command, which is covered next. The /PATH and /DESC options produce text files with Title, Size, and either Path or Description fields residing on a single line. The FORMAT option indicates that a user-specfied format be used. This topic will be covered in more detail in a separate section.
FORMAT "<field list>"
This command is complicated enough that is covered in a separate section of this document.
READTEXT "<Text file as written by SAVETEXT/LONG>"
The text file specified as <arg1> is read and *added* to the current list of file references. The file MUST be in exactly the same format as written by the SAVETEXT/LONG command. If the file does not contain 8 tabs on the first line, as it will, if saved with the correct format, the command is aborted with no indication other than the file count indicator within the FSP Log file will not increment.
Path Maintenance Commands
CLEARPATH "<guard>"
The path is stripped from all the entries in the current list, leaving only the file name as a reference. This may be used prior to SAVETEXT/PATHS for cleaner output, or it may be used as preparation for the 'BootPaths' Init Resource, used in conjunction with the SetPaths DA to provide default search paths within the Mac file system.
SETPATH "<new path>" "<guard>"
The paths of all the file entries in memory are changed to the specified string. (It goes without saying, as I already said it, that the guard argument must be either absent, null, or equal to a <true> value for this command to execute. This is just a reminder.)
CHANGEPATH "<new path>" "<guard>"
Each file reference is checked to see if it the file is reachable. If the file is where it's supposed to be, nothing else happens. If not, then the current path is replaced with the new path. A series of these commands may be used to search the disk for misplaced files.
CHECK/PATH "<guard>"
FSP will attempt to open every file in the list using the Pathname within the FileSection. If the file is not where RRHost thinks it is, then the entire disk is searched for the misplaced file. If it is found, the path is updated to the correct value. If it is not found, the file reference is marked for deletion. This command is restricted to HFS systems and will not work across multiple volumes. This capability may be added is there is demand.
This command takes a long time to execute, so it should be preceded with some CHANGEPATHs or SETPATHs so that the majority of file references are correct. Disk caching also helps. Nonetheless, this is the command the
allows the sysop to move files from one folder to another without worrying about RRHost finding it. Also, if a file is tossed into the trash, FSP will be unable to find it, and will mark it as deleted automatically.
If partial paths are used (':<name>'), the value of the symbol, "BBS", is inserted in front of the partial path, in order to simulate the default path that would exist if RRHost was executing. Also, if the resultant path begins with this same definition, then it is deleted so that partial paths are used in the file folder. That is, if BBS = 'HD20sc:BBS' and the path to file F1 is 'HD20sc:BBS:Sections:F1', then ':Sections:F1' will be used as the path.
CHECK/TYPE "<guard>"
The file type of each referenced file is examined. The 'Text' flag is be set if the file is of 'TEXT' type, and the MacApplication is set if the file has an 'APPL' type.
Delete Flag Modifying Commands
DELETE/DUPS "<guard>"
The current list is examined for duplicate entries; if any are found, the later one(s) in the list are marked for deletion. They are NOT automatically discarded, so that the list, if saved, can be examined with FileEdit or Host File Editor, to avoid tossing away the wrong file. Careful sorting prior to this command is advised, with a chronological sort (/DATE) preferred. If a PURGE follows this command, the marked entries are lost.
DELETE/TEXT "<File List>" "<guard>"
All files listed in the specified text file are deleted from the current set. The text file may be in any of the forms produced by FSP, or it may be a simple list of file titles, one title per line. Trailing blanks are allowed.
DELETE/AGE "<n>" "<guard>"
All file references with an upload date more than <N> days old will be flagged as deleted.
DELETE/ALL "<guard>"
DELETE/NONE "<guard>"
DELETE/TOGGLE "<guard>"
The 'ALL' causes all file references to be flagged as deleted. The NONE option will cause all files to be 'undeleted', while the TOGGLE option will cause deleted files to be marked as undeleted and valid files to be marked as deleted. Why? That's left "as an exercise for the reader", but there are some ways to put it to use.
INTERSECT "<sect>"
The list of files in memory is compared with the specified file section, and all references that do not occur in both places are removed from the list (based on Title).
Macros
DEFINEMACRO "<MacroName>"
A macro is a named sequence of FSP commands which can be invoked, as a sequence, by using the name as a command. This command defines a macro with the specfied name that includes all the FSP commands up to the next ENDMACRO command. During the definition of a macro, the associated commands are not executed, but are simply remembered for later use. Only one macro can be defined at a time, a limitation that simplified implementation and still met my functional requirements.
ENDMACRO
This terminates macro definition.
Example:
Define "Flag" "YES"
DEFINEMACRO "Process"
LOAD "@1"
SORT/DATE
SAVE "@1"
SAVETEXT/"@2" "@1.txt" "@3"
ENDMACRO
*
Process ":Uploads" "BRIEF" " Flag"
Process ":Downloads" "DESC" " Flag"
Process ":Otherloads" "DESC" " Flag-"
In the preceding example, ":Uploads", ":Downloads", and ":Otherloads" are all sorted by date. ":Uploads." and ":Downloads" are both used to produce the text reports ":Uploads txt" and ":Downloads.txt", with the /BRIEF and /DESC format respectively. (This shows a previously undocumented feature: options are also mapped through the symbol table; however, symbols used in this way must have be in upper case or they will not be recognized.) No text output is produced for ":Otherloads" as a guard value of "YES-" is used.
Other Commands.
DELETEFILE "<Mac file name>" "Guard>"
This will delete the specified file, as in remove it from the disk! It is intended to be used to clean up scratch files, or to remove temporary input
files. Use it with caution. It does not use or affect the 'Delete' flag.
At this point, users with programming experience are probably able to write simple FSP programs with no trouble, but others may still be in the dark. The solution? More examples, of course. But before we get to them, there are other topics to get out of the way...
Error-Handling
Version 2.3 of FSP has dramatically improved error-handling. In general, any detected errors will cause an immediate return to Finder. FSP 2.3 will not hang on bad pathnames and it will detect invalid application names that are "LAUNCH' targets. Unknown commands also cause immediate 'END', in the assumption that it's best to be conservative and not risk trashing a file section because of a possible error earlier in the FSP Control file. Report all problems to Topic 20, Section 3, Freesoft RT, GEnie.
Future Plans
Simple serial I/O may be implemented so that FSP execution wil echo through the modem if FSP is being executed as a type 50 command. Capabilities will include some simple interactive editing.
AnalyzeCL 0.88 provides a listing of recent file downloads/uploads which will be used in a future version to mark files based on access count and Last Date Referenced. Filter commands may be implemented that will flag files that have low/high access averages ((Current Date - Upload date)/ Access count).
Suggestions from users may also be incorporated, but I can't predict what those might be.
More Examples
A complete set of FSP examples is contained in a separate file named 'FSP Examples'. For an introductory look at FSP, follow the directions contained in the'FSP Demo Instructions'.
User-Defined Formats
Due to user requests, FSP now allows the user (RRHost Sysop) to define arbitrary formats for SAVETEXT output. The FORMAT command is used to define the format, which is used by SAVETEXT if the /FORMAT option is specified.
Pete Johnson deserves credit for the original idea, as well as for being the first registered user of FSP.
This documentation may be slightly intimidating, so skipping to the FORMAT examples may be advisable. Just playing around with some samples will probably teach you everything you need to know.
A FORMAT definition is composed of a field list, each of which has a default length. Fields may be upper, lower, or mixed case, and may be abbreviated.
Fields are separated by the '+' operator. If default lengths are not specified, or the previous field is not a comma or a string literal, or the next field is not a TAB, comma, or a CR, or END, then a blank is automatically inserted between fields. This sounds complicated, but it boils down to 'A blank is automatically inserted whenever it should be.' Use field width specification to override this feature. (The END does not have to be specified, but it's there! It's tacked on to the last field after FORMAT definition.)
The default length may be overwritten by following the field name with ':n', where n is the desired field width. If the default is used, the output will be left-justified and and padded with blanks so that the field in question will use the specified number of columns. If a field width specifier of 0 is used, the minimum number of columns is used.
Possible fields and default lengths.
TAB 0
CR 0
, 0
SECT 12
DELE 1
TITLE 12
SIZE 5
SIZEK 4
DESC 60
TYPE 6
UPLDR 31
VERS 9
DATE 8
CLRNC 3
PATH 40
'<string literal; may not contain a single quote>' 0
The meaning of most of the fields are almost self-explanatory or will become obvious in the examples, but SIZEK, SECT, and DELE bear further discussion.
SIZEK is the file size expressed in Kilobytes rather than bytes. This takes a little less space on the output line and is what interests most BBS users. Size is rounded up (naturally).
The SECT field is set to the source section whenever a file reference is LOADed or ADDed. Only the actual section name is used, which may be up to 31 characters in length. The default length is 12, because I use short
section names. The only way to see/display SECT is to use a user-defined format.
The DELE field is a single character output indicating whether the file is marked as deleted.
All formats must be completely specified within a single line, which means that the must be under 71 characters. Fields may be abbreviated in order to help meet this criteria. If an abbreviation matches more than one field name, the earliest one in the list is used. I.e. 'T' means 'TAB' rather than 'TYPE'.
Formats are also internally limited in length according to the following formula:
<# of fields>
+ 2 * <# of width specifiers>
+ <total character count of all string literals>
+ <# of string literals>
must be less than 100.
I consider it very unlikely that this limit will impact anyone, but if it does, or if the one-line limit is a problem, let me know, and I may extend FSP to allow larger formats.
Format Examples :
(Each sample output bracketed by '----...'.)
FORMAT "Title+Upldr+Date+CLRN"
---------------
FSP Control System Operator 1/25/87 0
---------------
; 'BULLETIN' format as suggested by Dave Game
DEFINE "BULLETIN" "FORMAT"
FORMAT "TITLE+SECT:12+SIZEK+DATE+UPLDR+CR:0+DESC"
SAVETEXT/BULLETIN "Txt Bulletin" ; Shows use of symbol as option.
---------------
FSP Control Demo 2K 1/25/87 System Operator
This is the desc.
---------------
FORMAT "TITLE:0+,+SECT:0+,+SIZEK:0+,+DATE:0+,+UPLDR"
---------------
FSP Control,Demo,2K, 1/25/87,System Operator
---------------
This one shows a string literal. Also, a CR always leaves
a leading blank on the next line. Use 'CR:0' to
line up subsequent lines.
FORMAT "TITLE+SECT:40+SIZEK:0+CR+'Path : '+Path:0"
---------------
FSP Control Demo 2K
Path : DataFrame:FSP Folder:FSP Control Demo
---------------
The next five examples are equivalent to built-in SAVETEXT
formats. When possible, use the built-in options, because
they will be faster.
PATH Format - Same as SAVETEXT/PATH
i.e. SAVETEXT/FORMAT = SAVETEXT/PATH
FORMAT "DELE:0+TITLE:13+SIZE:8+PATH"
---------------
FSP Control 2K DataFrame:FSP Folder:FSP Control Demo
---------------
DESC Format
i.e. SAVETEXT/FORMAT = SAVETEXT/DESC
FORMAT "DELE:0+TITLE:13+SIZE:8+DESC"
---------------
FSP Control 2K This is the desc.
---------------
; BRIEF Format
i.e. SAVETEXT/FORMAT = SAVETEXT/BRIEF
FORMAT "DELE:0+TITLE:12+T+VE:9+T+SIZE:5+T+DAT+T+CLRNC:5+T+UP"
---------------
FSP Control 1165 1/25/87 0 System Operator
---------------
; Default Format ; Field names are abbrev. to fit onto one line.
i.e. SAVETEXT/FORMAT = SAVETEXT
FORMAT "DEL:0+TITLE:12+T+VE:9+T+SI:5+T+DA+T+CL:5+T+UP+CR:0+TY:6+T+DES+CR:0+PA"
---------------
FSP Control 1165 1/25/87 0 System Operator
Text This is the desc.
DataFrame:FSP Folder:FSP Control Demo
---------------
The next two formats are not shown because the output is too long
to correctly show in a MacWrite file.
The LONG Format. A T is a TAB
i.e. SAVETEXT/FORMAT = SAVETEXT/LONG
FORMAT "DEL:0+TITLE:12+T+VE:9+T+SI:5+T+DA+T+CL:5+T+UP+T+TY:6+T+DES:60+T+PA"
; Almost LONG Format ; This one's too long as well.
; No tabs w/ automatically inserted blank field separators
FORMAT "DEL+TITLE+VERS+SIZE+DATE+CLRNC+UPLDR+TYPE+DESC+PATH"
Notes on FSP Path manipulation...
The CHANGEPATH and CHECK/PATH commands can free the RRHost sysop from a lot of headaches in terms of keeping RRHost file references pointing to the right folder. Even with the arrival of RRHost 1.3, the sysop can't move uploaded files from one folder to another without going into a File Editor and changing the path. These FSP commands, if included within a startup procedure, will automatically check all the file references and fix them if necessary.
As a simple example, the sysop might have all the file Sections within a folder named 'Sections', which is immediately under the same folder as Red Ryder Host. Any uploads (RRHost 1.3) will be placed in this folder. Assume the sysop wishes to collect all the uploaded files in another folder within 'Sections' named 'Files'. The following FSP sequence would allow the sysop to move the file without any extra work.
LOAD "<section name>"
CHANGEPATH ":Sections:Files"
CHECK/PATH
SAVE "<section name>"
The CHANGEPATH will check to see if the file is at the current path, ':Sections'. If it is found, no change occurs; if not, the path is set to the specified path, ":Sections:Files". It may or may not be there, but the sysop has decided that if it's not in the first folder, it may be in the newly specified folder. CHANGEPATH commands can be sequenced to name several potential paths, and once the file is found, the path will be unchanged by subsequent commands.
The CHECK/PATH again checks to see if the current path is valid and will do nothing if it is correct. If not, it will check the entire disk for the file. If found, the path is set to the correct value; if not, the file is presumed to be missing and is marked as deleted. This allows the sysop to remove files from the BBS just by dragging them to the trash. The next invocation of FSP will discover the absence and mark the file as gone, and BBS users will not see it anymore.
CHECK/PATH does take a lot of time, as there is no way to scan a 20 Meg drive very quickly, but it does work. Future versions may allow the search range to be restricted to subdirectories of the RRHost folder. Using a series of CHANGEPATH's in order to check likely folders cab reduce the number of file searches. This is analogous to checking likely spots for missing car keys prior to performing a systematic one-end-to-another combing of the house.
PURGE/DELETE is another command the bridges RRHost file Sections and the Mac File system. If this command is executed, all files within the current list that are marked as deleted are purged from the list AND deleted from the disk. This allows the sysop to delete files without having to remember to delete the file section entry and remove the actual file. All deletions and attempted deletions are logged in a file named 'FSP Deletions'. The 'Date' symbol is used to time stamp these records, which are appended to any previous data.
Feedback?
Those who have registered my other utilities know that I often include new features on request, so feel free to make suggestions, either via mail, the Hsv MUG BBS (205-881-8380), or Topic 21, Sect. 3, Freesoft RT, GEnie.
Shareware Plea
Over 60 people have downloaded FSP 2.1 as of the last time I checked, and registration is up, I'm glad to say. A total of 3 Freesoft RT users (and one other non-Freesoft participant) are registered users, for a 7% ratio. Assuming a 33% usage ratio (20 real users out of 60 DLs, which I suspect is low as FSP 1.3 also racked up 60 DLs and I don't think that 60 people would bother to DL 2.1 if they found FSP 1.3 lacking.), then this represents an 20% payment rate, which is quite good relative to RRHost shareware in general, but not very good in absolute terms. The reason I only ask $4.78 is that I have absolutely no question that FSP (and my other utilities) can and will save the RRHost Sysop at least $5 in time and labor with only one or two uses, as well as adding to the quality of the system. It's hard to tell exactly how many RRHost systems are up due to the disparity between utility DLs and RRHost (the actual program), but I'd guess there are around 100 actually in operation. What soes this mean?? A shareware DA with a potential market of 10,000 or so can get by if 1% of the users send in the requested fee, as the author will get still receive some reward. The same does not hold true of as small as user base as RRHost. If you use the program, send in your money. If you don't, send in the reason you don't, and the next release may satisfy your needs. I'm certain this request holds for the other RRHost utility authors as well.
